Network Segmentation for Homelabs

Practical network segmentation patterns for separating trust zones in a homelab

created: Sat Mar 14 2026 00:00:00 GMT+0000 (Coordinated Universal Time) updated: Sat Mar 14 2026 00:00:00 GMT+0000 (Coordinated Universal Time) #networking#security#homelab

Introduction

Network segmentation reduces blast radius by separating devices and services into smaller trust zones. In a homelab, this helps isolate management systems, user devices, public services, and less trusted endpoints such as IoT equipment.

Purpose

Segmentation is useful for:

  • Limiting lateral movement after a compromise
  • Keeping management interfaces off general user networks
  • Isolating noisy or untrusted devices
  • Applying different routing, DNS, and firewall policies per zone

Architecture Overview

A practical homelab usually benefits from separate L3 segments or VLANs for at least the following areas:

  • Management: hypervisors, switches, storage admin interfaces
  • Servers: application VMs, container hosts, databases
  • Clients: laptops, desktops, mobile devices
  • IoT: cameras, media devices, printers, controllers
  • Guest: devices that should only reach the internet
  • Storage or backup: optional dedicated replication path

Example layout:

VLAN 10  Management   192.168.10.0/24
VLAN 20  Servers      192.168.20.0/24
VLAN 30  Clients      192.168.30.0/24
VLAN 40  IoT          192.168.40.0/24
VLAN 50  Guest        192.168.50.0/24

Traffic should pass through a firewall or router between zones instead of being bridged freely.

Design Guidelines

Segment by trust and function

Start with simple boundaries:

  • High trust: management, backup, secrets infrastructure
  • Medium trust: internal application servers
  • Lower trust: personal devices, guest devices, consumer IoT

Route between zones with policy

Use inter-VLAN routing with explicit firewall rules. Default deny between segments is easier to reason about than a flat network with ad hoc exceptions.

Use DNS intentionally

  • Give internal services stable names
  • Avoid exposing management DNS records to guest or IoT segments
  • Consider split DNS for remote access through Tailscale or another VPN

Minimize overlap

Use clean RFC 1918 address plans and document them. Overlapping subnets complicate VPN routing, container networking, and future site expansion.

Configuration Example

Example policy intent for a firewall:

Allow Clients -> Servers : TCP 80,443
Allow Management -> Servers : any
Allow Servers -> Storage : TCP 2049,445,3260 as needed
Deny IoT -> Management : any
Deny Guest -> Internal RFC1918 ranges : any

Example address planning notes:

192.168.10.0/24  Management
192.168.20.0/24  Server workloads
192.168.30.0/24  User devices
192.168.40.0/24  IoT
192.168.50.0/24  Guest
fd00:10::/64     IPv6 management ULA

Troubleshooting Tips

Service works from one VLAN but not another

  • Check the inter-VLAN firewall rule order
  • Confirm DNS resolves to the intended internal address
  • Verify the destination service is listening on the right interface

VPN users can reach too much

  • Review ACLs or firewall policy for routed VPN traffic
  • Publish only the required subnets through subnet routers
  • Avoid combining management and user services in the same routed segment

Broadcast-dependent services break across segments

  • Use unicast DNS or service discovery where possible
  • For mDNS-dependent workflows, consider a reflector only where justified
  • Do not flatten the network just to support one legacy discovery method

Best Practices

  • Keep management on its own segment from the beginning
  • Treat IoT and guest networks as untrusted
  • Document every VLAN, subnet, DHCP scope, and routing rule
  • Prefer L3 policy enforcement over broad L2 access
  • Revisit segmentation when new services expose public endpoints or remote admin paths

References